In a procedural software system, such as Java or C++, a software procedure is located in memory. A thread of execution may invoke the procedure by calling the memory location. Frequently a procedure will present a typed interface defining the arguments that must be supplied to the procedure. In languages such as Java and C++ the type of the argument to be supplied is declared by the procedure and any execution invocation must supply instances of positionally correlated arguments.
For example here is a simple Java method interface:                void javaMethod(int aValue, String bValue);This procedure might be invoked with code similar to:        
javaMethod(100, “Hello World”);
The call to execute the procedure “javaMethod” must ensure that the correct type of argument is provided in the correct positional location—in this case, the first argument must be an integer, the second must be a String object. This approach can be called ‘Procedure Invocation with Positionally Correlated Typed Arguments’ (PIPCTA).
Some languages, such as Python or PL/SQL, extend the PIPCTA model to support named arguments. For example, here is a Python method definition, which uses named arguments, and supplies default values:                def pythonMethod(someInteger=0, someString=“Default”):The following method invocations are equivalent:        
    pythonMethod(100, “Hello World);pythonMethod(someInteger=100, someString=”Hello World”)pythonMethod(someString=”Hello World”, someInteger=100)
As those skilled in the art will appreciate, by employing named arguments the positional dependence of the arguments is removed resulting in increased code flexibility for the caller of the procedure.
Languages in which interfaces are untyped offer further relaxation of the constraint between procedure and caller. In the examples shown above, the Python language demonstrates both named arguments and untyped interfaces.
The World Wide Web (WWW) is a distributed client-server software system in which information resources are hosted on Web-servers. Web-clients and Web-servers implement support for the HyperText Transport Protocol (HTTP) and adhere to a standard means of identifying Web resources.
A Uniform Resource Identifier (URI) identifies a Web resource. A URI is an untyped location in a resource address space. Specifically, for information resources in the WWW system, the URI is a Uniform Resource Locator (URL).
The HTTP protocol defines a small set of actions that may be applied to a resource. Most commonly a client will request a copy of a resource by issuing an HTTP ‘GET’ request for the URL of the resource. To physically perform this action the client will parse the URL to obtain the name of the resource's host Web-server. It will then employ DNS to locate the IP address of that Web-server. Using TCP/IP networking it will then issue the HTTP GET request to the port of the host server's HTTP protocol handler. The Web-server will respond by sending a stream of bytes consisting of HTTP protocol message headers followed by a copy of the resource itself.
A Web-server must provide an HTTP transport protocol handler and a means of delivering a copy of a resource for a requested URL. Most importantly, a Web-server must be configured to perform a mapping from the logical URI web-address of a resource to the physical embodiment of the information resource.
In a simplest form a Web-server, such as Apache, might map a file system directory into the web URI address space:
http://www.1060.org/myDirectory/=>/var/www/myDirectory/ such that a GET request for a resource below the URL path /myDirectory/ will obtain a copy of the file located in the server's directory /var/www/myDirectory/                http://www.1060.org/myDirectory/myFile.html=>/var/www/myDirectory/myFile.html        
The WWW is a remarkably robust and adaptive application. It has grown to have a huge diversity of client and server implementations and its success rests on the basis of the common adherence to the HTTP protocol and URL addressing.
The Web does not have a formal architecture and yet is highly tolerant such that it accepts a wide range of styles of Web application development. Representational State Transfer (REST) is a post-hoc formal description of one such application development style. Its premise is to describe a Web application development model utilizing the HTTP protocol and URL requests with characteristics that approach an ideal. Much debate remains about what the ‘ideal’ is but it includes scalability (both scaling-out and scaling-up) and adaptability.
One notable point is that REST suggests that when a resource is served as the result of a computation (for example by mapping a URL to the execution of a CGI script or JSP engine), then it is good practice to explicitly embody the information necessary to compute the resource in the URL of the resource.
Suppose for example we have a map service, which dynamically generates an image of a geographical location. Its primary REST interface might have the URL:                http://www.1060.org/cgi-bin/mapserver        
To generate an image it needs two pieces of information, namely the latitude and longitude of the geographical point at which to center the map (for simplicity lets assume all map images are a fixed size of 10×10 kilometers). Two possible ways of explicitly expressing in the URL the information required for the computation of the map by the mapserver can be considered. First a positional URL path approach where latitude and longitude values are expressed by position in the URL path:
http://www.1060.org/cgi-bin/mapserver/51.536/-2.390/
An alternative approach is to use URL query parameters to provide named arguments: http://www.1060.org/cgi-bin/mapserver?latitude=51.536longitude=-2.390
The first approach is analogous to PIPCTA function invocation. The second is similar to named argument invocation. In either case the computed resource is uniquely identified by its URI. Explicitly supplying the information needed to compute the resource as part of its URI allows that a computed resource can be cached for future reuse, where the URI is used as the primary key in the cache. Transparent caching is a very important attribute for the scalability of Web applications. Applications, which adhere to the REST architectural style, are sometimes described as ‘RESTful’.
Operating systems, such as Unix or Linux, locate executable application code using an environmental context. When a shell process executes it has associated with it a collection of environment variables. These variables provide the context for the execution. When the shell makes a kernel call to execute a secondary process—for example ‘ls’ to list a directory—the kernel uses the PATH variable containing an ordered list of directories to search the filesystem for an executable file called ‘ls’. The PATH variable's listing of directories in effect represents a series of searchable resource address spaces in which executable code may be located.
When a child process is forked, by default it inherits the environmental context of its parent. It is possible to programmatically modify the environment variables within a process so as to provide a dynamic execution context but due to the limited nature of environment variables this would be a very unwieldy way to develop systems.